Skip to content

Conversation

codeboten
Copy link
Contributor

The idea w/ this matrix is to provide end users a clear picture of what is implemented for each language implementation. Ideally, the matrix will be:

  1. auto generated from the kitchen-sink
  2. automatically filled in for every implementation via a test

In the short term, the automation for fill in the implementation details could be manual, but ideally that would be short-lived for the sake of users and implementors.

The idea w/ this matrix is to provide end users a clear picture of what is implemented
for each language implementation. Ideally, the matrix will be:

1. auto generated from the kitchen-sink
2. automatically filled in for every implementation via a test

In the short term, the automation for fill in the implementation details could be manual, but
ideally that would be short-lived for the sake of users and implementors.

Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
@jack-berg
Copy link
Member

jack-berg commented Apr 14, 2025

Hey @codeboten - I put together a branch with a little demo that shows how the code generation might work: https://github.com/jack-berg/opentelemetry-configuration/tree/generate-compliance-matrix

It wrote a fast / dirty script to:

  1. Read in all the JSON schema files from ./schema
  2. Resolve all the $refs
  3. Iterate through all the types and generate markdown

See an example of the output of markdown generation here: https://github.com/jack-berg/opentelemetry-configuration/blob/generate-compliance-matrix/schema.md

@marcalff
Copy link
Member

@jack-berg Could you check your demo branch ? I can't see the script or the generated markdown. Thanks.

@jack-berg
Copy link
Member

Oops looks like I had some copy paste errors on the links. Fixed.

This still needs a decent amount of work before its ready for PR, but I think its conceptually right.

@marcalff
Copy link
Member

Oops looks like I had some copy paste errors on the links. Fixed.

This still needs a decent amount of work before its ready for PR, but I think its conceptually right.

Thanks, I can see it now.

Some suggestion below

Instead of presenting:

  • a table with "Property, Type, Description, C++, C#, erlang, etc"

consider presenting:

  • a table with "Property, Type, Description"
  • a table with "Property, C++, C#, erlang, etc"

Also, extension points are missing.

In Samplers for example, I expect an entry for extension points, and the possibility for each SIG to document if extension points are suported or not.

@marcalff
Copy link
Member

@codeboten @jack-berg

Any news on this ?

opentelemetry-cpp is about to complete the declarative configuration implementation, and I really would like a place to report details, node by node, in the matrix.

This will help to keep track of changes to the model going forward, at a very detailed level, like for example diffs in modeling between 1.0-rc.1 and 1.0-rc.2.

Also, the specifications now use some tooling with a yaml file per SIG, could the same be used here ?

This will avoid merge collisions between SIGs reporting implementation completeness, and improve the git history (git blame).

@jack-berg
Copy link
Member

@marcalff I'll work on refining some ideas sometime in the next 7-10 days.

@jack-berg
Copy link
Member

See #312

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants